École Nationale des Sciences Géographiques
Décembre 2017 - Damien DUPORTAL
This work is licensed under a http://creativecommons.org/licenses/by/4.0/
Training Engineer @ CloudBees
Docker & Apple fanboy.
Human stack focused
Rock climber
Contact:
Twitter: @DamienDuportal
Github: dduportal
eMail: damien.duportal@gmail.com
TBD.
TBD.
"Gestion de Code Source"
Les Gestionnaires de Code Source, également connus comme "Version Control Systems" (VCS):
Sont des systèmes logiciels
Conservent toutes les modifications apportées à une collection de fichiers, dans le temps
Permettent de partager ces changements
Fournissent des fonctionnalités de merge et de suivi des modifications
Pour collaborer efficacement sur un même référentiel de code source
Aide à la résolution de conflits
Partage de contenu facile
Pour conserver une trace de tous les changements : On parle de source unique de vérité (Single Source of Truth)
Historique complet des modifications
Possibilité de retour arrière à tout moment
Locaux
Centralisés
Distribués
Plus vieux type, ancêtre de tous les autres
Uniquement historique de modification
Utilise une "base de donnée de versions" des fichiers
Stockage uniquement des différences ("diff")
Pas de partage
Exemple: rcs (toujours dans Apple XCode Tools)
Couvre historique ET partage
La "base de données de versions" est stockée sur un serveur central
Chaque client ne possède qu'une seule version du code
Apprentissage très facile, limité sur la résolution de conflits
Exemples: CVS, SVN, Perforce, TFS
La "base de données de versions" est distribuée par duplication sur chaque noeud
Exemples: Git, Mercurial, Bazaar, Monotone
Hébergés dans le Cloud
Hébergé "à la maison"
SCM as a Service
Le serveur centralisé est un service hébergé par un fournisseur
Avantages:
Pas de temps/énergie passés sur la gestion
Associent au SCM d’autre services : gestionnaire de tickets, wiki, éditeur de texte online, etc.
Risque: Votre code est hébergé par un tiers
Exemples: GitHub, Bitbucket by Atlassian, Amazon CodeCommit, Visual Studio Online by Microsoft, SourceForge, GitLab.com, etc.
Pour pallier au risque précédent, on trouve des versions "On-Premide" (généralement payantes)
Le monde de l’Open Source fourni également des solutions à héberger soit-même
Très souvent gratuit et on peut le corriger
Temps et énergie à consacrer
Exemples: Gitlab, Gitea, Gogs, Bazaar server, VisualSVN Server, etc.
diff: un ensemble de lignes "changées" sur un fichier donné
changeset: un ensemble de "diff" (donc peut couvrir plusieurs fichiers)
commit: Action de sauvegarder un changeset dans la base de données des versions.
Le dernier commit dans l’historique est aliasé comme "HEAD"
Abstraction d’une version "isolée" du code
Concrètement, une branche est un alias pointant vers un "commit"
On intègre une branche dans une autre en effectuant un merge
Un nouveau commit est créé, fruit de la combinaison de 2 autres commits
Une Pull Request (ou "Merge Request") est une procédure de revue de code avant intégration
Voici quelques motifs d’utilisation des SCMs :
"Centralized" Flow
"Feature Branch" Flow
"Git" Flow
"GitHub" Flow
Une seule branche par fonctionnalité
"Infrastructure as Code" :
Besoins de traçabilité, de définition explicite et de gestion de conflits
Collaboration requise pour chaque changement (revue, responsabilités)
Code Civil:
Un peu de lecture :
Le code est donc sujet à erreurs: Conséquences?
Les tests identifient ces erreurs, dans un but de correction
Le test logiciel est une pratique suivant 2 piliers :
Valider que le logiciel remplisse les rôles qui lui sont confiés
Rechercher les fautes pour les corriger, améliorant la qualité du système
Automatiser : répétition et reproductibilité
Test Manuel à considérer dans peu de cas, quand :
Coût de l’automatisation dépasse sa valeur
Automatisation impossible
SUT: "System Under Testing". Défini les frontières du système.
Test Double: Terme générique désignant un sous-ensemble simplifié du "S.U.T.". Exemples: Mock, Stub, Spy, etc.
Boîte Blanche: Tester avec une vue interne du SUT
Boîte Noire: Tester le SUT sans connaissance préalable de ses mécanismes interne
La question primordiale est: "Que voulez-vous tester ?"
En fonction de la réponse, différent types de tests peuvent être utilisé (liste NON exhaustive) :
Unit testing
Integration testing
Smoke testing
Functional Testing
Non-Regression testing
Acceptance testing
Focalisé sur le plus petit sous sytème possible du SUT, en "boîte blanche"
Tests indépendants les uns des autres
Ordre d’exécution non important
Utilisation de Test Doubles pour simuler le "reste" en bon fonctionnement
Vérifier l’intégration entre différents sous-systèmes
Le SUT est en "boîte blanche"
But : Fail Fast en "boîte blanche"
Valide les fonctions "de base" du système
On parle parfois de "Sanity Checking"
If it smokes, it’s bad
Vérifie que le logiciel se comporte comme prévue par les personnes en charge de la fabrication
Pas de biais d’inteprétation
Le SUT est en "boîte noire"
Vérifie que le SUT a un comportement stable dans le temps
Focalisation sur bug qui ne doit pas revenir
Le SUT est en "boîte noire"
Correcting a single bug may introduce several more.
Également connu sous l’acronyme "UAT" User Acceptance Testing
Vérifie que le logiciel se comporte comme attendu par l’utilisateur
Biais de communication inclus
Le SUT est en "boîte noire"
Fonction des temps d’exécutions, des coûts de corrections, et des valeurs ajoutées. Contextuel.
TDD: Écrire les tests unitaires avant le code
BDD: Privilégier language naturel et interactions
"Given, When, Then"
Moins de technique. Valeur ajoutée pour l’utilisateur.
Continuous Integration is a software development practice where members of a team integrate their work frequently. Usually each person integrates at least daily - leading to multiple integrations per day.
Construire et intégrer le code en continu
Le code est intégré souvent, au moins quotidiennement pour que l’intégration soit un non-évenement
Chaque intégration est validée par une construction automatisée avec tests
But : Détecter les fautes au plus tôt
Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove.
Continous Delivery (CD)
Diminuer les risque liés au déploiement
Permettre de récolter des retours utilisateurs plus souvent
Rendre l’avancement visible par tous
How long would it take to your organization to deploy a change that involves just one single line of code?
Suite logique de l’intégration continue:
Chaque changement est potentiellement déployable en production
Le déploiement peut donc être effectué à tout moment
Your team prioritizes keeping the software deployable over working on new features
Continuous Deployment
Version "avancée" de la livraison continue:
Chaque changement est déployé en production, de manière automatique
Question importante: En avez-vous besoin ?
Avez-vous les mêmes besoin que Amazon Google ou Netflix ?
"Software Supply Chain"
"Feedback loop" / "Boucle de feedback"
Problèmatique : réagir rapidement pour corriger une faute
"Au plus tôt, au moins cher"
Problème #1: Avoir un retour
Problème #2: Réagir systématiquement sur un retour
Problème #3: Avoir confiance
Quels acteurs du système ?
Quel médium de communication ?
Quel déclencheurs et quelles limites ?
Culture à construire, les outils suivent facilement
Industrialisation du logiciel
Modélisation de la chaîne de valeur ("Value Stream Mapping")
"Fast is cheap": Piloté par le concept de la défaillance rapide ("fail fast")
Stage ("étape"): Élément de base
Abstraction atomiques d’un ensemble d’actions
Exemple: "Build", "Run Unit Tests"
Possibilité de parallèlisation
Gate ("Porte"): Transition entre 2 étapes
Manuel ou automatique
Peuvent être conditionnelles
Déclenchement initial : un changement dans la base de code
Chaque étape peut produire des livrables: on parlera d'Artefacts dans ce cours
Le déploiement est ce qui permet de rendre le logiciel prêt à l’usage
Un "déploiement" est exécuté vers un environnement
Production
Préproduction ("staging") / recette ("qualification")
Tests
"Disaster Recovery Environment"
Commencer par un "Produit Minimum Viable" (MVP) puis itérer
S’efforcer d’appliquer les bonne pratiques
Optimiser le Pipeline (lors des itérations)
Réutilisation des artefacts: "Only Build Your Binaries Once"
Arrêt du Pipeline dès qu’une faute est identifiée: "Fail Fast"
Identifier si un artefacts n’est pas déployable (tests…)
S’assurer qu’une même version de la base de code est utilisée à tout moment pour un Pipeline donnée
Paralléliser les étapes
Arrêt du Pipeline si une "branche" est en erreur
Sinon: étape inutile à supprimer
Les "gates" manuelles peuvent également être paralleliser
relation "1-N": N "gates" manuelles déclencheront N étapes parallèles
Un peu de lecture :
Your organization uses information to create value
Information is valuable and must follow:
Confidentiality
Integrity
Availability
Implementing Security practices envorce those rules
Security is the set of practices and tools to fight and prevent threats
It’s all about following those principles:
Know the system
Least privilege: If you do not need to do it, you do not have the right to do it.
Defense in Depth: Systems are layered. Put security on all layers.
Preventing is good. Detection is better: Continuous monitoring and detection.
Handling "Least privileges" concepts makes you manage the AAA concepts:
Authentication
Authorization
Accounting
Authentication is the set of tools and procedures that identify a user with enough confidence
When police check your ID, it is authentication
Using a login and a password is an authentication
Biometrics are also a type of authentication
2FA, that stands for "Two Factor Authentication" is a stronger authentication scheme
Once a given user is authenticated, need to determine the actions this user should have the right to do
Authorization always occurs in the context of authentication
Authorization grants access rights to:
Resources: Tasks, objects and/or actions to manipulate
Roles: A set of rights grouped together by commodity
Requesters: User or group that has roles assigned, and wants to manipulates resources
It is easy to visualize and enforce with a Security Matrix
Occurs in the context of a user both authenticated and authorized.
It measures resources used or consumed by the user during access.
This can be amount of data, compute resources, or system time.
It enforces limits when they are defined to protect system.
Related to system measurement, capacity planning and feedback loops
Defense in Depth is not an easy subject, but we are focusing on the Credentials
Given the previous AAA context
A lot of systems for stages of pipelines (SCM, CI Server, Environment, WebServices, etc.)
How to enforce homogeneity of AAA ?
Credential management is the practices and tools that avoid leaking authentication information to non authorized users.
Security has to be meta: how to enforce security itself ?
Auditing the security processes and system is a method to validate them.
It can be seen as a type of Acceptance Testing:
Needs to be run continuously
Should be done by someone other than the user being audited
It can be related to external certification for external confidence (e.g. PCI)
Security is a required discipline that must be taken into account from the beginning
It is a large subject but enforcing the rules is a big win
Implementing AAA framework is a good way to start
Security is related to feedback: which action to take when a problem arises ?
Measurement is not an option, but a must have
Some recommended readings on this subject: